REMARKS 

Reconsideration and allowance of this Application are respectfully requested in light of 
the foregoing amendments and following remarks. 

At the outset, Applicants want to thank Examiner Garg and Examiner Haq for the Office 
Interview with Applicants' conducted on August 3, 2004. 

Claim 17 has been amended to clarify that classes and attributes participate in 
relationships. 

The text of original claim 19 has been added to the specification, since it is part of the 
original disclosure, before hne 20 of page 15, i.e., before the last paragraph on page 15. No new 
matter has been added by this amendment to the specification. 

Claim 21 has been amended to recite a 'parametric' search engine, which is supported at 
least at page 9, lines 16-22 of the specification. 

Claim 23 has been amended to clarify that for, a leaf class, the recited attribute 
relationships is a leaf class to an attribute. 

Claim 25 has been amended to clarify that the recited value relationships is an attribute to 
a value of the attribute. 

No new matter has been added by any of the foregoing claim amendments. 
SUMMARY OF OFFICE INTERVIEW 

During the Office Interview conducted on August 3, 2004, the following topics were 
discussed. 

1. Claims 23 and 25 respectively recite that "... said attribute relationships are 
between a leaf class and an attribute..." and "...said value relationships are 
between an attribute and a value of the attribute. Examiner Haq clarified that 
he was alleging in the Office Action that no such relationship was disclosed 
between the recited entities and that there was disclosed only an association of the 
recited entities, i.e., "an association of a leaf class to an attribute" and "an 
association of an attribute to a value". 

2. Claim 19 recites the limitation "a master database not normally accessible to said 
buyer ...". Applicants pointed out that there is disclosure of a master database 
that a buyer cannot directly search but is searched by a 'back office' on behalf of 
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a buyer with the search results being provided to the buyer for selection 
therefrom. Examiners suggested amending the language of Claim 19 to recite that 
the search is by a 'back office' and deleting the language "not normally 
accessible". 

3. Applicants asserted that object oriented database technology is a tool that does not 
motivate modifications to a reference because one 'can' use the tool to modify the 
reference to achieve a limitation of Applicants' claimed invention. Examiners 
stated that if one 'can' use object oriented database technology to modify a 
reference that this is sufficient motivation to modify a reference and therefore 
sufficient motivation to modify the data structure of the Erickson reference. 
Applicants disagreed, stating that there had to be motivation in the references 
themselves. 

Applicants also argued that it would not have been obvious to one skilled 
in the art to use object oriented database technology because the claimed 
invention as well as the cited reference is for a transaction-oriented system and 
long ago (in the 1970's) object oriented database technology was found wanting 
in performance because the transaction path is too long using such object oriented 
database technology. Therefore, even absent any motivation in the prior art 
reference to modify the data structure thereof, Applicants argued that no one 
ordinarily skilled in the art would use this technology either in the claimed 
invention or in the Erickson invention because the incorporation of this object 
oriented database technology would make an application much less efficient for 
its intended purpose. 

4, Applicants pointed out that the Office Action's admission that the Erickson 
reference does not teach that the first database lacks a desired item and that 
Erickson teaches a plurality of update mechanisms to keep the first and second 
database synchronized. Further, Applicants asserted that Erickson explicitly 
teaches the second or master database is updated only by the service provider 
thereof from submissions of updates by buyers and suppliers to the service 
provider. Applicants argued that it is the service provider, and not the buyers and 
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suppliers, that is maintaining the second or master database and distributing 
updates to the local database copies thereof. Applicants further pointed out that 
searching the master database in addition to a local replicate by the buyers and 
sellers is nowhere taught by Erickson, would not only defeat the disclosed 
purpose of Erickson's invention, to make the accessing of data more efficient by 
having a local copy, but would not guarantee that the master contained any 
updates. 

hi support of their argimient that Erickson does not teach accessing a 

second database when a first database does not contain a desired item, Applicants 

pointed out that Erickson teaches 

"The information stored in central database 16 may be accessed 
through service provider 14 or, alternatively, a portion of the 
information in central database 16 may be copied by a buyer 10 or 
supplier 12 into a local database such as local database 18 or local 
database 20, In some embodiments, it may be preferable to 
distribute portions of central database 16 to various local 
databases, such as local database 18 or local database 20. This will 
allow a buyer or supplier to access desired information locally 
rather than establishing contact with service provider 14 in order 
to access central database 16, Such a distributed database model 
often gives faster access to desired information, but introduces the 
additional complexity of maintaining current copies of local 
databases in a variety of locations. However, particular buyers or 
suppliers may wish to assume a larger share of the maintenance 
responsibilities for faster access to desired information." (Col. 7, 
Lines 19-35; emphasis added) 

In addition, Erickson teaches how local databases are maintained: 

"Embodiments within the scope of this invention may comprise 
means for maintaining a local database. As previously explained, 
both buyers and suppliers may maintain local databases, such as 
local database 34 or local database 36 of FIG. 2. In FIG. 3A, the 
means for maintaining a local database is illustrated, for example, 
by local database maintenance processing block 60. Local database 
maintenance processing block 60 is responsible for maintaining 
local database 36. Although the details of local database 
maintenance processing block 60 are presented below, in essence, 
local database maintenance processing block 60 is responsible for 
requesting updates from central database 24 and receiving update 
information and storing it back into local database 36. In FIGS. 
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3A and 3B, such a request is illustrated by local database update 
request message 62. As previously explained in conjunction with 
FIG. 2, such a function may also be accomplished by using 
information request message 56. However, in the embodiment 
illustrated in FIG. 3, information request message 56 is illustrated 
for the purpose of indicating that specific information may be 
requested from central database 24. Local database update request 
message 62, on the other hand, is a general message intended to 
update all information in local database 36. In other words, 
information request message 56 may be used in FIG. 3 to request a 
new record from central database 24. Local database update 
request 62 may then be used to maintain the requested records in a 
current state." (Col. 12, Lines 22-48; emphasis added) 

Nowhere, Applicants assert, does Erickson teach searching a first database (local 
database) and then, if a desired item is not located in the first database, searching 
a second database (central/master). Erickson teaches a local database for the 
express purpose of not incurring the performance and cost penalties associated 
with searching a remote database and thus teaching away from searching a 
remote database under any circumstances. 
5. AppHcants pointed out that a 'parametric' search engine is disclosed in the 
specification that presents attributes associated with a specific item leaf class and 
valid values associated with each attribute for selection by a user. Examiners 
suggested and applicants agreed to amend claim 21 to limit the recited search 
engine to a parametric search engine, as disclosed by Applicants. 

Claim Obiections 

A. Claims 22 and 23 are ob jected to because of informalities 

Office Action Position 

The Office Action alleges that claims 22 and 23 recite limitations "said class 
relationships" and "said attribute relationships" for which there is insufficient antecedent basis in 
the claims. 

Applicants' Response 

Applicants respectfully traverse. 



8 



Claim 17 (from which both claims 22 and 23 depend) recites, in pertinent part, "a second 
catalog database, wherein each unique catalog item stored within said second catalog is 
identified with respect to class relationships, attribute relationships, and value relationships; ..." 
(emphasis added). This limitation of claim 17 recites relationships among (between and to) any 
of class, attribute, and value and is intended to provide antecedent basis for any relationships 
among and between any members of the group consisting of class, attribute, and value and 
therefore there is antecedent basis for claims dependent from claim 17 for a relationship of a leaf 
class to an attribute and an attribute to a value, including claims 22 and 23. Applicants further 
point out that at least at page 25 lines 4 et seq. relationships among (between and to) any or all of 
class/attribute/value are defined as well as illustrated in FIG. 10 item 224, 222, 230, 234 and 208 
and FIG. 9 items 154, 156, 158, 160, 178 and FIG. 8 items 104 (leaf class) 106, 110, 112, 132. 
FIG. 7A illustrates the relationships among attributes that allow a graphical comparison among 
attribute values that is described at least at page 11, lines 4-12. The hierarchical relationship of 
classes is disclosed at least at page 11, lines 19 through page 12, line 17 and the hierarchical 
relationship among class and values is illustrated at least in FIG. 5 for a class 'Gases' and value 
'Airgas specialty gases' and value 'Gases in Lecture Bottles'. A class has a value, a subclass has 
a value, and a class has a related attribute and the related attribute has a value, and finally a 
values have relationships as well, as shown in FIG. 7 where there are two * Gases in Lecture 
Bottles' shovra: ammonia and carbon dioxide, but having different part numbers and descriptions 
even though these gases all have the same attributes (image, product, description, merchant, 
product number, manufacturer, unit of measure and price in this example). In a given hierarchy, 
a Non-leaf class has attributes and values, e.g., the Gases of FIG. 5 can be fiirther broken down 
as illustrated and the Thinkpads of FIG. 6 can be fiirther broken down into 'Notebook', Ten 
Notebook' and 'Tablet'. 



9 



Claim Rejections 
B. Claim Rejections - 35 U,S>C> §112 

1. Claims 19, 23, and 25 are rejected under 35 U.S.C, 112, first paragraph, as failing to 
comply with the written description requirement for containing subject matter 
which was not described in the specification in such a way as to reasonably convey 
to one skilled in the relevant art that the inventors, at the time the application was 
filed, had possession of the claimed invention, 

1.1 Claim 19 

Office Action Position 

Claim 19 is rejected under 35 U.S.C. 112, first paragraph, for reciting the negative 
limitation "... not noraially accessible...". The Office Action alleges there is no support for this 
limitation in the AppUcants' specification. 
Applicants' Response 

Applicants respectfully traverse. 

At page 15, line 6 et seq. and as illustrated in FIG. 8, the Applicants disclose how a buyer 
may employ a structured requisition to obtain the item the buyer is seeking fi:om a database not 
normally accessible to the buyer 22. The specification discloses that not only are the classes 
from the catalog database 32 that have already been searched, automatically included in the 
structured requisition but " ...all the classes fi-om the master or global catalog database are also 
made available to the user to expedite the item location process. Additionally, attribute and even 
value information may be made available fi-om the master or global catalog database... ". 
Further, at page 17, line 5 et seq. it is the back office 24 and not the buyer 22 that is searching 
the master database and at hne 9 an electronic mail message is sent to the buyer with a hyperlink 
to a screen containing matches and if buyer selected an item from this screen, at line 16 
Applicants disclose that buyer 22 is preferably immediately reinserted back into procurement 
system 20 as shown at point 130, returning to point 98 of FIG.2, so that the purchase process 
may be completed." Contrary to the allegation of the Office Action, Applicants assert that this 
disclosure is of "a master database not normally accessible to said buyer including the desired 
item, said special requisition being used to search for the desired item in said master database" as 
recited by claim 19. 
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Finally, claim 19 is an original claim and therefore is part of the original disclosure. 
Applicants have amended the specification to incorporate therein the text of claim 19 so that 
there is explicit support for the limitations thereof. 

Therefore, the claimed subject matter of claim 19 is described in the specification in such 
a way as to reasonably convey to one skilled in the relevant art that the inventors, at the time the 
application was filed, had possession of the claimed invention and the rejection should be 
withdrawn. 

1.2 Claims 23 and 25 

Office Action Position 

Claim 23 and 25 are rejected under 35 U.S.C. 112, first paragraph, because these claims 
recite the limitations "...said attribute relationships are between a leaf class and an attribute" and 
"...said value relationships are between an attribute and a value of the attribute", respectively. 
The Office Action alleges that there is no support for these limitations in the Applicants' 
specification. 
Applicants' Response 

Applicants respectfully traverse. 

At the outset. Applicants point out that relationships are defined between entities and that 
saying that 'A is related to B' means that 'there is a relationship between A and B' and one 
ordinarily skilled in the art of database would realize that when a claim recites that a leaf class is 
related to an attribute (and vice versa) that what is being recited is that there is a relationship 
between a leaf class and an attribute and not just 'an association of a leaf class to an attribute'. 
Applicants' assertion is supported at least at page 25 lines 4 et seq. wherein relationships among 
any or all of class/attribute/value are defined and which are illustrated as well in FIG. 10 item 
224, 222, 230, 234 and 208 and FIG. 9 items 154, 156, 158, 160, 178 and FIG. 8 items 104 (leaf 
class) 106, 110, 112, 132. Further, FIG. 7 A illustrates the relationships between attributes that 
allow a graphical comparison between attribute values that is described at least at page 1 1 lines 
4-12. The hierarchical relationship of classes is disclosed at least at page 11, line 19 through 
page 12, line 17 and the hierarchical relationship among class and values is illustrated at least in 
FIG. 5 for a class 'Gases' and value 'Airgas specialty gases' and value 'Gases in Lecture 
Bottles'. A class has a value, a subclass has a value, and a class has a related attribute and the 
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related attribute has a value, and, finally, values have relationships as well, as shown in FIG. 7 
where there are two 'Gases in Lecture Bottles' shown: ammonia and carbon dioxide, but having 
different part numbers and descriptions even though these gases all have the same attributes 
(image, product, description, merchant, product number, manufacturer, unit of measure and price 
in this example). 

A leaf class has related attributes and these attributes have related values, i.e., a 
relationship exists between a leaf class and its attributes and between these attributes and their 
values. For example, the Thinkpads of FIG. 6 can be further broken down into types (an 
attribute) 'Notebook', 'Pen Notebook' and 'Tablet'. This is a relationship of 'type' or 'species' 
between a leaf class and an attribute that is relevant to characterizing a product for retrieval 
(searching the catalog to find the item). Notebooks appear somewhere else in the hierarchy of 
product classes as a subclass of personal computer, which is a subclass of computer, for example. 
The ability to capture this relationship between a leaf class (Thinkpad) and an attribute (type) is 
essential to being able to represent different supplier breakdowns of products. One supplier 
might supply only laptops while another might supply a whole range of personal computers and 
these two suppliers would have different catalog structures for their products. 

Therefore, contrary to the allegation of the Office Action, Applicants assert that the 

respective limitations of claims 23 and 25 "said relationships are between a leaf class and an 

attribute" and "...said value relationships are between an attribute and a value of the attribute" are 

more than adequately supported in Applicants' specification and the rejections should be 

withdrawn. The language of claims 23 and 25 has been clarified to emphasize these points. 

2*0 Claims 19, 23, and 25 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter 
which applicant regards as the invention. 

2.1 Claim 19 

Office Action Position 

The Office Action alleges that this claim recites the limitation "...not normally 
accessible..." and that this is a relative limitation which renders the claim indefinite. The 
Examiner notes that either a database is accessible or it is not accessible to a user and that the 
limitation is purely subjective and not defined by the claim or the specification. Furthermore, the 
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Examiner alleges that one or ordinary skill in the art would not be reasonably apprised of the 
scope of the invention and that for examination purposes, the Examiner assumes that the 
database is accessible to the user since even a database which is "not normally accessible" is at 
some point accessible to a user. 
Applicants' Response 

As pointed out above with respect to the 35 U.S.C §112 first paragraph rejection of claim 
19, the master database does not have to be normally accessible to the user in order for the user 
to make a selection from a search done on behalf of the user by the 'back office'. Applicants 
again assert that this limitation is more than adequately disclosed at page 15, line 5 et seq., and as 
illustrated in FIG. 8, the Applicants disclose how a buyer may employ a structured requisition to 
obtain the item the buyer is seeking fi-om a database not normally accessible to the buyer 22. 
The specification discloses that not only are the classes from the catalog database 32 that have 
already been searched, automatically included in the structured requisition but " ...all the classes 
from the master or global catalog database are also made available to the user to expedite the 
item location process. Additionally, attribute and even value information may be made available 
from the master or global catalog database... Further, at page 17, line 5 et seq. it is the back 
office 24 and not the buyer 22 that is searching the master database and at line 9 an electronic 
mail message is sent to the buyer with a hyperlink to a screen containing matches and if buyer 
selected an item from this screen, at line 16 AppUcants disclose that buyer 22 is preferably 
immediately reinserted back into procurement system 20 as shown at point 130, returning to 
point 98 of FIG.2, so that the purchase process may be completed." Contrary to the allegation of 
the Office Action, Applicants assert that this disclosure is of "a master database not normally 
accessible to said buyer including the desired item, said special requisition being used to search 
for the desired item in said master database" as recited by claim 19, wherein the searching is 
done on behalf of the buyer 22 by the 'back office'. 

Further, to prevent another from claiming a process that only rarely lets a buyer have 
access and thereby avoid infiingement, Applicants have recited 'not normally available'. 

However, since claim 19 is an original claim and therefore is a part of the original 
disclosure, the specification has been amended to incorporate the text of claim 19 so that claim 
19 is now hterally supported by the specification. 



13 



For all the above reasons, the rejection is overcome and should be withdrawn. 
2.2 Claims 23 and 25 
Office Action Position 

The Office Action alleges that it is unclear what is meant, respectively, by the recited 
limitations "...said attribute relationships are between a leaf class and an attribute" and "...said 
value relationships are between an attribute and a value of the attribute." The Office Action 
further alleges that the specification does not provide an adequate description of these 
Hmitations. 
Applicants' Response 

Applicants respectfiilly traverse. 

Applicants repeat the argimients presented for the 35 U.S.C. §112 first paragraph 
rejection of these claims that at least at page 25 lines 4 et seq. relationships among any or all of 
class/attribute/value are defined as well as illustrated in FIG. 10 item 224, 222, 230, 234 and 208 
and FIG. 9 items 154, 156, 158, 160, 178 and FIG. 8 items 104 (leaf class) 106, 110, 112, 132. 
Further, FIG. 7A illustrates the relationships among attributes that allow a graphical comparison 
among attribute values that is described at least at page 11 lines 4-12. The hierarchical 
relationship of classes is disclosed at least at page 11 lines 19 through page 12 line 17 and the 
hierarchical relationship among class and values is illustrated at least in FIG. 5 for a class 
'Gases' and value 'Airgas specialty gases' and value 'Gases in Lecture Bottles'. A class has a 
value, a subclass has a value, and a class has a related attribute and the related attribute has a 
value, and, finally, values have relationships as well, as shown in FIG. 7 where there are two 
*Gases in Lecture Bottles' shown: ammonia and carbon dioxide, but having different part 
numbers and descriptions even though these gases all have the same attributes (image, product, 
description, merchant, product number, manufacturer, unit of measure and price in this example). 

A leaf class has associated, i.e., related, attributes and values. For example, the Thinkpads 
of FIG. 6 can be further broken down into types (an attribute) ^Notebook', Ten Notebook' and 
'Tablet'. This is a relationship between a leaf class and an attribute that is relevant to 
characterizing a product for retrieval (searching the catalog to find the item). Notebooks appear 
somewhere else in the hierarchy of product classes as a subclass of personal computer that is a 
subclass of computer, for example. The ability to capture this relationship between a leaf class 
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(Thinkpad) and an attribute (type) is essential to being able to represent different supplier 
breakdowns of products. One supplier might supply only laptops while another might supply a 
whole range of personal computers and these two suppliers would have different catalog 
structures with different attributes, i.e., different relationships between their leaf classes and 
attributes. 

Therefore, contrary to the allegation of the Office Action, Applicants assert that the 
respective limitations of claims 23 and 25 "said relationships are between a leaf class and an 
attribute" and "...said value relationships are between an attribute and a value of the attribute" are 
more than adequately supported in Applicants' specification and the rejection should be 
withdrawn. 

3.0 Claims 17-20, 22, and 24 are rejected under 35 U.S,C. 103(a) as being unpatentable 
over Erickson (U.S. Patent No. 6,014,644) in view of 
http://www.research.ibm.com/iournals/si/361/srinivasan.html "Object persistence in 
object-oriented applications'^ hereinafter referred to as IBM 

Office Action Position 

With regard to claims 17 and 18, the Office Action alleges that the buyer may search the 
first or second database to identify suppliers that offer goods of interest to the buyer (Col. 8, lines 
28-30, lines 51-67; Col. 12, lines 58 - Col. 13, line 1) and because buyers and suppliers are 
allowed to add data into the databases (Col. 3, lines 13-42; Col. 7, line 46-Col. 8, line 27) that it 
is inherent that a first database lacks a desired item in the system of Erickson. The Office Action 
admits that Erickson does not teach that each unique item stored within the first and second 
catalog databases is identified with respect to class, attribute, and value relationships but alleges 
that IBM teaches that Object-oriented database management systems use class, attribute, and 
value relationships to store and identify items within a database and that it would have been 
obvious to one of ordinary skill in the art, at the time the invention was made, to incorporate the 
teachings of IBM into the system of Erickson because one would have been motivated to do so 
in order to avoid the impedance mismatch that exists with relational data models and databases. 

Regarding claims 19 and 20, the Office Action admits that Erickson does not teach a 
special requisition that uses said class, attribute, and value relationships but alleges that IBM 
teaches Object Query Language that allows for searching a database. Further, the Office Action 
admits that Erickson does not teach that the databases are not updated according to said class, 
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attribute, and value relationships but alleges that since Erickson places no restriction on when the 
buyers and suppliers can add data into the database it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to decide not to update a database. 

With regard to claim 22, the Office Action admits that Erickson does not each that the 
class relationships are hierarchical among classes but alleges that IBM teaches that inheritance 
provides for a hierarchy among classes. 

With regard to claim 24, the Office Action admits that neither Erickson nor IBM teach 
that attributes comprise static, differentiating, and dynamic. The Office Action alleges, without 
providing any motivation therefor, that it would have been obvious to one of ordinary skill in the 
art to incorporate these features into the cited prior art. Further, the Office Action alleges that 
Applicants have not disclosed an advantage, use, purpose or problem solved by these attribute 
types. The Office Action continues, that one of ordinary skill in the art would have expected 
Applicants' invention to perform equally well with the teachings of the cited prior art because 
any item has data associated with it which describes the item uniquely and based on all the 
foregoing, it would have been obvious to one of ordinary skill in this art to modify the cited prior 
art to obtain the invention as specified in the claims. 
Applicants Response 

Applicants respectfiilly traverse. 

Applicants point out that, as discussed above, Erickson teaches away from searching both 
databases. Each of the teachings of Erickson for locally storing a replicate of a part of a central 
database is directed to eliminating searching the remote central (master) database. All of 
Erickson' s many teachings of ways for keeping the local databases in synchronization with the 
central database are directed to maintaining currency of local databases for the express purpose 
of not accessing the central database to do searching. Nowhere does Erickson teach or suggest 
"an item selection procedure, said procedure relying on said relationships to search for the 
desired item within said second database when it is not located within said first database" as 
recited by claim 17. In effect, Erickson teaches away firom searching the central database by 
teaching a local copy of relevant portions of the central database and teaching keeping the local 
database current with the contents of the central database. 
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Applicants also point out that there is no teaching or suggestion of a relational database 
anywhere in the claimed invention or in Applicants' specification nor is there any such teaching 
in the cited reference, Erickson, so there would be absolutely no motivation to address a non- 
existent impedance mismatch therewith. 

Applicants also point out that Erickson has not identified any problem with the data 
structure of the database taught by Erickson and there would be no motivation whatsoever to 
change the data structure of Erickson to the data structure of the present invention, absent the 
Applicants' claimed invention. The court in in re Sang Su Lee, 277 F.3d 1338, (Jan, 18, 2003) 
held that there must be some explicit motivation to modify a reference in the prior art itself and 
that an Applicant's invention cannot be used as a roadmap against applicant, as is being done by 
the Office Action in making this rejection. The court held that doing so is improper hindsight. 

With further regard to claims 17 and 18, the cited combination of references does not 
overcome the admitted deficiencies of Erickson, namely, that Erickson does not teach that each 
unique item stored within the first and second catalog databases is identified with respect to 
class, attribute, and value relationships and with regard to claim 19 that Erickson does not teach a 
special requisition that uses class, attribute, and value relationships to identify the desired item. 
It is not sufficient that there is a tool that uses class, attribute and value relationships to store and 
identify items within a database to motivate combining that tool with Erickson and modifying the 
data structure and searching method taught therein and certainly the alleged motivation to 
overcome impedance mismatch between relational data models and databases does not motivate 
modifying Erickson to identify each unique item with respect to class, attribute, and value 
relationships as claimed by claims 17-19 and the rejection of claims 17-19 should be withdrawn. 
No problem is either identified by Erickson or is otherwise being solved by such a modification 
because a relational data model is not inherent in the teaching of Erickson. A simple indexed 
file can suffice for a storage structure of Erickson's data. 

Regarding claim 20, an Object Query Language is not a special requisition and does not 
overcome the admitted deficiency of Erickson, namely, that Erickson does not teach a special 
requisition that uses class, attribute, and value relationships and the rejection of claim 20 should 
be withdrawn for at least this reason. 
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In addition, with regard to claim 20, Applicants' respectfully state that Claim 20 recites, 
in pertinent part "...one of said databases being updated with said desired item according to said 
class, attribute, and value relationships..." and nowhere does any of Apphcants' claims recite not 
updating a database or a decision not to update a database. All that is recited is that one of said 
databases is updated. The point being that Erickson does not teach updating any database 
according to said class, attribute and value relationships because, as admitted by the Office 
Action, Erickson does not teach that each unique item stored within the first and second database 
is identified with respect to class, attribute, and value relationships and the rejection of claim 20 
should be withdrawn. 

Applicants' respectfully assert, with regard to claim 22, that an object inheritance 
hierarchy is not equivalent to the hierarchy among catalog classes, as disclosed and claimed by 
Applicants. An Object class as taught by the cited IBM reference, is a general construct 
comprising inter alia data definition and methods whereas a class of the claimed invention is a 
unique data ID describing a specific catalog category for a product, e.g., 'Gases' as a class 
(catalog category) having related subclasses of 'Airgas Specialty Gases' and 'Gases in Lecture 
Bottles'. The class of claim 22 is not a general construct for defining data and methods as taught 
by IBM. The Examiner is confusing a general construct. Object class, for defining data, methods 
and an inheritance hierarchy with data of a single type, product, arranged in a hierarchy. 
Applicants assert that one ordinarily skilled in the art would realize they are not the same and are 
not equivalent. The alleged motivation by the Office Action to incorporate the teachings of IBM 
into the system of Erickson, namely, to efficiently search and maintain an object-oriented 
database is irrelevant to motivate modifying Erickson' s non-hierarchical data structure to include 
classes relationships that are hierarchical among classes and the rejection of claim 22 should be 
withdrawn. Nowhere does Erickson teach a hierarchy of catalog classes so that modifying 
Erickson's data structure to achieve a hierarchy would not be useful, i.e., would not make 
Erickson more efficient since a hierarchy has no use in the teachings of Erickson, and is 
therefore not motivated. Erickson only teaches identifying each product by a unique ID so that 
at most Erickson implies an index of these unique IDs to aid search. 

Regarding claim 24, contrary to the allegation of the Office Action that Applicants have 
not disclosed that static, differentiating, and dynamic attributes provide an advantage, are used 
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for a particular purpose or solve a stated problem, Applicants have defined a Stock Keeping Unit 
(SKU) as a unique identifier for an item based on its differentiating attributes. The advantage of 
the differentiating attributes is that together they form a unique ID for an item and this is 
expressly defined on page 9, line 23 to page 10, line 4. Differentiating among products certainly 
is useful to both buyer and supplier. Applicants teach that intrinsic properties do not vary based 
on SKU, they do not contribute to an item's unique ED but are still used to describe 
characteristics of an item. Intrinsic properties are useful to both buyers and suppliers when 
searching for items because they provide differentiation not based on SKU. Dynamic attributes 
are associated with an item at buy time, e.g., such as price and quantity on hand, and keeping a 
price current and providing a quantity on hand certainly are useful to a buyer as well as a 
supplier and do not have to be disclosed since their advantages would be obvious to one 
ordinarily skilled in the art, e.g., to ordinary buyers and suppliers. The advantages of 
differentiating, dynamic, and static attributes derive fi-om their definitions (provided in 
Applicants specification as explained above) and their obvious use by suppliers to describe their 
products and by buyers to search for and select products. 

Further, Applicants assert that, contrary to the allegation of the Office Action, one of 
ordinary skill in the art would not expect Applicants' invention to perform equally well with the 
teachings of the cited prior art because only unique IDs are taught in the cited prior art and one 
skilled in the art would assume that there is always an advantage in having more detailed 
information about an item in order to make an informed purchase decision. Therefore, assuming 
that the additional information provided by Applicants' intrinsic and dynamic attributes is non- 
trivially related to a buying decision, i.e., these types of attributes are useful, and since there is no 
motivation in the prior art to include these useful attributes in the cited prior art, the rejection of 
claim 24 should be withdrawn. 

Finally, Applicants assert that each of these allegations of the Office Action is 
impermissible hindsight, examples of using the Applicants' invention as a roadmap against 
Applicants. The court in In Re Sang Su Lee, 277 R3d 1338, (Jan, 18, 2003) held this is 
impermissible hindsight and that cited references must contain a specific motivation to combine 
cited references and there is none here. The only problem identified in the prior art of Erickson 
is keeping the local databases synchronized with the central database. Modifying the data 
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structure of Erickson with IBM, as suggested by the Office Action, does not solve this problem. 
Erickson has not identified any problem with the structure of classification data taught therein 
and most specifically Erickson has not taught a relational database, so that overcoming an 
impedance mismatch therewith using IBM is also not motivated. Therefore, the Office Action 
has failed to make out a prima facie case of obviousness with regard to claims 17-20, 22, and 24 
and the rejections of these claims should be withdrawn. Claims 17-20, 22, and 24 are therefore 
allowable. 

Therefore, in view of all the above discussions, neither Erickson nor IBM, alone or in 
combination, can be relevant prior art for the present claimed invention, the Office Action has 
not established a prima facie case of obviousness and the rejections of claim 17-20, 22, and 24 
should be withdravra. Claim 17 is allowable and claims 18-25, dependent therefi-om are 
allowable for at least this reason. 

4.0 Claim 21 is rejected under 35 U.S>C, 103(a) as being Unpatentable over Erickson 

(US Patent 6,014,644) in view of 

http://www.research.ibmxonfi/journal/s.i/361/srinivasan.html "Object persistence in object - 
oriented applications" hereinafter referred to as IBM and further in view of Official 
Notice , 

Office Action Position 

The Office Action admits that the cited prior art does not teach that a search engine 
performs the item selection procedure (i.e., database query). However, the Office Action takes 
Official Notice that it is old and well known in the art to use a search engine to search a database 
and that it would have been obvious to one of ordinary skill in the art, at the time the invention 
was made, to incorporate a search engine into the system of Erickson as modified by IBM to 
provide a user with a user- friendly interface for searching a database. 
Applicants Response 

The rejection is moot in view of the amendment of claim 21, the rejection should be 
withdrawn, and claim 21 is allowable. 

Claim 21 also depends from allowable claim 17 and is allowable for at least this reason. 
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Conclusion 



In view of the foregoing remarks, all stated objections and rejections of the Office Action 
have been overcome and this Application is in condition for allowance. Early notice to that 
effect is earnestly solicited. 

If any issues remain which may be best resolved through a telephone communication, the 
Examiner is requested to kindly telephone the undersigned at the local, Washington D.C. 
telephone number listed below. 



NOW/att 

ATTORNEY DOCKET NO. TPP31401A 

STEVENS. DAVIS, MILLER & MOSHER, L.L.P. 

1615 L Street, NW, Suite 850 

P.O. Box 34387 

Washington, D.C. 20043-4387 

Telephone: (202) 785-0100 
Facsimile: (202) 408-5200 



Date: August 30, 2004 




Registration No. 45,208 
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